project management

GOV.UK beta goes live. I'm proud.

in ,

 

At 9h.03m.9s on 31 Jan GOV.UK, the beta version of the UK Government's single domain project, was released to the public for the first time.  I was the Delivery Manager on the project and it feels like an awesome achievement and I am very proud to have been part of it.

I think we've delivered a slick product.  It's beautiful (imo), reduces obfuscation, is task focused on user needs and uses search based architecture rather than browse hierarchies. It's only a start and there is so much more to do but early feedback on Twitter and GetSatisfaction has been extremely encouraging so far.

Also, unusually for UK Government IT projects it came in on time and slightly under budget which is testament to the skills of the team, our iterative approach and  (cough) careful management.  More on that in another post.

Most gratifying is that we've been given permission (or did we just seek forgiveness?) to develop this project out in the open.  From the beginning we've been tweeting and blogging about our emerging thinking and code has been available for public scrutiny on GitHub.  Only this week the first member of the public made a pull request, made some changes to the code, committed and we deployed the same day.  This is fundamentally changing the way Government IT works.

The Government Digital Service (GDS) is a new organisation within the Cabinet Office.  It's exciting times, with some commentators saying its like having the coolest start-up at the heart of government.  I can confirm it feels like this from the inside too.  It's been an amazing journey so far and I know we're only just beginning to crank it up.

Related links

Using a kanban system to track editorial work

in

 

With close to a thousand bits of short and long-form content to produce, the @GovUK project is a big editorial project, not just a development gig. Spreadsheets are making us cross-eyed and can be crippling so we are experimenting with a Kanban wall to prioritise and track work.

The idea is that you map the workflow stages of a process (in our case editorial) and limit the amount you prioritise, the amount of work in progress and keep moving tickets from left to right.

I like this way of working a lot. We're running this process alongside our sprint wall which focuses on the development tasks and we track completed items on a weekly basis. Bottlenecks become apparent as tasks pile up in one column or another.  It's a simple way of focusing on the task in hand and gives us tickets to point at in our daily stand-ups.

Early days yet but early signs are that it's helping.

Agile does work in government

in ,

Some feel that agile is poorly suited to government and is just a fad. One of the principle objectives for this project was to demonstrate that an agile approach can work. For us that meant delivering a prototype that:

  • demonstrated a user-centred central government, single domain website
  • used a small, multi-disciplinary team of developers, designers, editors, sat in the same room
  • came in for a budget of £261k and was delivered by 10th May

I drew upon Scrum for a structure to manage the project but I knew not to over do it.  In my experience projects can quickly become about the process and not the product, with everyone getting hung up on big ‘A’ Agile.  I claim no particular expertise – I am a practitioner and you have to allow room for pragmatism.

Working iteratively, within an agreed upfront budget and time box allowed us to get a prototype out the door quickly.  In that time we were able to deliver two releases of the software before finally releasing to the public 3 days ago. We have been pretty open throughout the development and that has been useful for us as a team and hopefully for those people outside of the project room with an interest too.

This is my view of how things developed and some of the challenges we faced.

Obsession with user need

We spent the first two weeks in February recruiting a team from inside and outside of government, talking through the scope, agreeing some design rules and agreeing a vision for the Alphagov product based around the recommendations of Martha’s report.

We ended those two weeks with a list of priortised user needs (based around search analytics from Directgov, Hitwise and departments), roughly grouped into functional areas and stuck to the wall. Each card (or user story) represented a user need, prioritised roughly from left to right and top to bottom.

Crucially also there was a fair amount of@tomskitomski and @memespring‘s product experience. All this was more than good enough to get on with twelve weekly development sprints.

Small ‘a’ agile

We kept the rhythm of the project with daily stand up meetings, weekly show and tells, and certainly in the early stage of the project we’d get our heads together to work out as a team what worked and what hadn’t.

We talked a lot – regular interruptions across the room were accepted, sometimes there were creative tensions but crucially everyone worked alongside each other in the same room with a focus on delivering a product.

The product evolved as we moved through the weeks and our view of the product changed.  A language developed around ‘glue’, ‘gov’, ‘tools’ ‘guides and answers’.  User stories cards became a mix of user needs and  placeholders for a bunch of tasks.

We used a backlog and estimated the size of each story card  to negotiate the weekly work loads. But the team did not get hung up on the concept of velocity (apart from @jamesweiner who thrived on story points and would try to game the system to deliver a ‘winning’ week).

Mostly though we organised ourselves around what felt right.  In fact, for the last two weeks we relied totally on a list on the wall of ‘things to do’ – because it was the quickest and simplest way of polishing up what we’d already done.

The now infamous Sprint #5!

We (or rather I) didn’t get everything right. By the end of sprint 5 I was just about ready to hang up my Excel and opt for a life at the RSPCA.

One of the challenges was balancing momentum with getting the team together.  I started on the project in the last week of Jan, by Feb the 5th we had Richard on board along with Jimmy, Dave, Helen, and Peter.  It wasn’t until mid-March that we had afull team in one place all of the time.  This was disruptive and made syncing design and development through iterations of development and working together that much harder.  In Sprint 5 we only delivered a couple of stories and Sprint 6 was equally tough but thanks to a monumental effort and some pragmatic concessions, we delivered.  From then on we properly started to fly.

A talented, self-organising team.

Most of the Alphagov team are individually capable of designing and building digital products and despite everyone having a role with a title, the boundaries are difficult to establish in practice.  We knew who the drummer was, that be Russ, but everyone was capable of being the lead guitarist – so to speak.

Like every other project team it took us time to settle into each other but by working so closely in one room, with space to draw on the walls, with the minimum of interruptions and a single focus around product we were able to produce a lot in a short space of time.  We launched a day later than we announced, partly to do with the rhythm of comms, but happy to suck up an extra day to tweak and take the password off in good order.

The quality and amount of feedback and active debate on Twitter, Facebook andGetSatisfaction since then has been phenomenal.  We are responding to feedback and able to iterate the product day by day. That’s got to be a more effective way of consulting with people to design products that help them deal with the Government online.

This project was not just about the team in the room. A tip of the hat to Chris Chant and Tony Singleton for taking a chance and giving us the space to do this, and to  Jimmy Leach, Neil Williams, Darren Leafe, Simon Everest, David Pullinger, Neil Franklin and many others in the Civil Service that helped make it possible.